#lang scribble/base

@(require "shared.rkt")

@title[#:tag "testing"]{@;{Testing}测试}

@; -----------------------------------------------------------------------------
@section[#:tag "test-suite"]{@;{Test Suites}测试套件}

@;{Most of our collections come with test suites. These tests suites tend to
 live in @tt{collects/tests/} in the PLT repository, though due to
 historical reasons, a few collections come with their own local test
 suites.  If you add a new collection, create a new test suite in the
 @tt{tests} collection.}
我们的大多数产品都附带测试套件。这些测试套件往往位于PLT存储库中的@tt{collects/tests/}中，尽管由于历史原因，有些集合带有自己的本地测试套件。如果添加新集合，请在@tt{tests}集合中创建新的测试套件。

@;{Run the test suites before you commit. To facilitate testing, we urge you
 to add a @tt{TESTME.txt} file to your collections. Ideally, you may also
 wish to have a file in this directory that runs the basic tests.  See the
 @hyperlink["https://github.com/racket/racket/tree/master/collects/2htdp/"]{2htdp},
 which is one of the collections with its own testing style.  The file should
 describe where the tests are located, how to run these tests, and what to
 look for in terms of successes and failures. These files are necessary
 because different collections have different needs for testing, and
 testing evolved in many different ways in our history.}
在提交之前运行测试套件。为了方便测试，我们建议你向集合中添加一个@tt{TESTME.txt}文件。理想情况下，你可能还希望此目录中有一个运行基本测试的文件。请参阅@hyperlink["https://github.com/racket/racket/tree/master/collects/2htdp/"]{2htdp}，这是具有自己测试风格的集合之一。该文件应该描述测试的位置、如何运行这些测试，以及从成功和失败的角度寻找什么。这些文件是必需的，因为不同的集合对测试有不同的需求，并且测试在我们的历史中以许多不同的方式发展。

@;{After you commit, watch for and read(!)
 @hyperlink["http://drdr.racket-lang.org/"]{DrDr}'s emails. Do @emph{not}
 ignore them. If you have tests that are known to fail and fixing this
 requires a lot of work, consider splitting your test directory into two
 parts: @tt{success} and @tt{failure}. The former is for tests that should
 succeed now, and the latter is for tests that are currently expected to
 fail. See the
 @hyperlink["https://github.com/racket/racket/tree/master/collects/tests/typed-scheme"]{Typed
 Racket testing arrangement} for an example. When you create such
 @tt{failure} tests, you may wish to disable DrDr's checking like this:
@verbatim[#:indent 2]{
  git prop set drdr:command-line "" <file> ...
}
 This is a Racket-specific @tt{git} command.}
承诺后，注意阅读（！）@hyperlink["http://drdr.racket-lang.org/"]{DrDr}的电子邮件。千万不要忽视他们。如果你已知的测试失败，并且需要进行大量的测试，请考虑将测试目录分成两部分：@tt{成功}和@tt{失败}。前者用于现在应该成功的测试，后者用于当前预期将失败的测试。见@hyperlink["https://github.com/racket/racket/tree/master/collects/tests/typed-scheme"]{Typed
 Racket测试约定}。当你创建这样的@tt{失败}测试时，你可能希望禁用DrDr的检查，如下所示：
@verbatim[#:indent 2]{
  git prop set drdr:command-line "" <file> ...
}
这是一个特定于Racket的@tt{git}命令。

@; -----------------------------------------------------------------------------
@section[#:tag "test-bang"]{@;{Always Test!}总是测试！}

@;{When you debug an existing piece of code, formulate a test case first. Put
 it into the test suite for the component so the mistake will never be
 accidentally re-introduced and add a note that points to the problem
 report.  Second, modify the code to fix the mistake. Do this second to be
 sure you didn't introduce a mistake in your tests; it is all too easy to
 think you have fixed a mistake when in reality your new test just doesn't
 properly reveal the old mistake.  Third, re-run the test suite to ensure
 that the mistake is fixed and no existing tests fail.}
当调试现有代码时，首先制定一个测试用例。将它放入组件的测试套件中，这样错误就不会被意外地重新引入，并添加一个指向问题报告的注释。其次，修改代码以修复错误。做第二步，以确保你没有在测试中引入错误；当实际上你的新测试没有正确地揭示旧错误时，很容易认为你已经修正了错误。第三，重新运行测试套件，以确保错误是固定的，并且没有现有测试失败。

@;{If there is no test suite and you aren't sure how to build one, then ask on
 the developer mailing list. Perhaps people will explain why there isn't
 one or they will sketch how to create one. Please don't ignore the
 problem. If you cannot build a test suite, you have a few options:}
如果没有测试套件，并且你不确定如何构建测试套件，请在开发人员邮件列表中询问。也许人们会解释为什么没有一个，或者他们会描绘如何创建一个。请不要忽视这个问题。如果无法构建测试套件，则有几个选项：

@itemlist[#:style 'ordered

  @item{@;{Add functionality to the library to enable testing. Of course,
  adding functionality means adding external documentation.  Robby and
  Matthew have done so for the GUI library, and there is now a large
  automated test suite for DrRacket. So even GUI programs can come with
  extended test suites.}
           向库中添加功能以启用测试。当然，添加功能意味着添加外部文档。Robby和Matthew已经为GUI库做了这样的工作，现在有一个用于DrRacket的大型自动化测试套件。因此，即使是GUI程序也可以附带扩展测试套件。}

  @item{@;{Add an end-to-end test that may have to be verified by a human.
  For example, it might be hard to test Slideshow, so you could create a
  slide set and describe what it should look like so future maintainers to
  verify when @emph{they} make changes. Consider this the @emph{last and
  least desirable} option, however.}
          添加一个可能需要人工验证的端到端测试。例如，可能很难测试幻灯片放映，因此你可以创建一个幻灯片集并描述它应该是什么样子，以便将来的维护人员验证@emph{他们}何时进行更改。不过，请将此视为@emph{最后也是最不可取的}选项。}
]
@;
 @;{The lack of tests for some collection will not disappear overnight. But if
 we all contribute a little bit, we will eventually expand the test suites
 to cover the entire code base, and future generations of maintainers will
  be grateful.}
某些集合缺乏检测不会在一夜之间消失。但是，如果我们都做出一点贡献，我们最终将扩展测试套件以覆盖整个代码库，未来几代的维护人员将不胜感激。
